개요

projected 볼륨에 대해서 보다가 문득 궁금증이 생겼다.
보통 ConfigMap은 볼륨 마운팅된 경우 변경 사항이 생겼을 때 해당 정보가 실시간으로 파드의 파일시스템에 반영된다.
그러나 만약 subPath를 이용해 사용한 경우에는 동적으로 반영되지 않는데, 과연 projected 볼륨에서는 어떻게 작동할까?

추가적으로 생긴 궁금증 중 하나는 같은 리소스를 두번 사용할 수 있는지에 대한 것.

그냥 내가 가진 궁금증들을 살짝 터는 시간을 가질 것이다.

환경 세팅

로컬 환경에서 Kubernetes v1.32 - Penelope 버전으로 실험을 진행한다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: config
data:
  test: value
---
apiVersion: v1
kind: Pod
metadata:
  name: projected
spec:
  containers:
  - name: myapp
    image: centos
    command:
      - sh
      - -c
      - "tail -f /dev/null"
    volumeMounts:
      - mountPath: /config
        name: project
  volumes:
    - name: project
      projected:
        sources:
          - configMap:
              name: config
              items:
                - key: test
                  path: config

세팅은 매우 간단하게 해주었다.

describe를 해보면 projected가 들어간 것이 보인다.

데이터는 실제로도 잘 들어갔다.

configmap 값 수정하기

edit을 이용해 컨피그맵을 수정해본다.

그러나 결과는 변하지 않았다.
마치 subPath를 사용할 때처럼 동작한 것이다.

configMap을 통째로 준다면?

  volumes:
    - name: project
      projected:
        sources:
          - configMap:
              name: config

특정 키를 이용해서 데이터를 주입하는 형식은 컨피그맵 자체를 마운팅해주도록 동작하지 않기 때문에 발생한 일일 수도 있다는 생각이 들었다.
그래서 이번에는 통째로 넣어본다.

현재는 처음 데이터가 들어가있다.

이번에도 똑같이 데이터를 수정했다.

조금 기다리자, 이번에는 성공적으로 데이터 수정이 반영된 것이 보였다.

같은 configMap 여러 번 쓰기

  volumes:
    - name: project
      projected:
        sources:
          - configMap:
              name: config
          - configMap:
              name: config

응 이건 딱 봐도 안 될 것 같다.

응? 잘 됐다..

다만 중복으로 넣었어도 데이터는 하나만 들어간 것이 확인됐다.
어차피 이렇게 쓰는 케이스가 있진 않을 거라 생각하지만, 사용자의 실수를 무시해버리는 게 썩 좋아보이진 않는다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: config
data:
  test: value
  this: is sparta
---
apiVersion: v1
kind: Pod
metadata:
  name: projected
spec:
  containers:
  - name: myapp
    image: centos
    command:
      - sh
      - -c
      - "tail -f /dev/null"
    volumeMounts:
      - mountPath: /config
        name: project
  terminationGracePeriodSeconds: 0
  volumes:
    - name: project
      projected:
        sources:
          - configMap:
              name: config
              items:
                - key: test
                  path: testt
          - configMap:
              name: config
              items:
                - key: this
                  path: what

이번에는 데이터를 추가하고, 각 키를 따로 설정해본다.
위에서 확인한 바로, 이렇게 쓸 경우 최소한 동적 업데이트는 진행되지 않을 것이다.

각각의 설정이 제대로 반영되어 들어간 것이 확인된다.

결론

projected 볼륨은 다양한 데이터를 한꺼번에 모아서 컨테이너에 주입하기 위해 만들어진 볼륨 유형이다.
그러나 데이터 자원들이 가지는 특성인 동적 업데이트가 제대로 이뤄지지 않는다면 활용하는데 애로사항이 있을 것이라 생각했다.
하지만 보통 configMap을 쓰는 방식으로 사용한다면 똑같이 동작하기에 크게 문제는 없을 것으로 보인다.

추가적으로 똑같은 리소스를 여러 번 쓰는 것은 문제가 되지 않는다.
다만 별도의 설정 없이 같은 방식으로 설정하는 경우 별도의 에러가 출력되지 않으며, 그냥 하나의 리소스로서 컨테이너에서 보이게 된다.
솔직히 그냥 코드 까보기 귀찮아서 직접 실험해본 건데, 조금 의외의 결과였다.
이게 의도한 대로 구현된 것인지는 모르겠다.
다만 별도의 세팅 없이 중복이 되도록 양식을 작성한 경우에는 검증 실패를 시키는 게 사용성에 있어서는 더 좋지 않을까 한다.

관련 문서

참고